Release 10.1A: OpenEdge Development:
Progress Dynamics Basic Development

Writing distributed applications

The basis of the logic structure of the ADM2, which carries over into Progress Dynamics, is to support running applications in a distributed environment using the OpenEdge® AppServer technology. There are several reasons for this approach.

First, consider a client/server system with an application interface running on an MS Windows machine and a database running on a separate server machine. This kind of system can have serious performance limitations. All the records involved in running the application are passed from server to client, including records read to execute schema trigger procedures. Every CAN-FIND or other database access operation requires a message between client and server. The major goals of the OpenEdge® AppServer are:

To help you minimize this traffic, by allowing procedures that require no user interface to execute entirely in a Progress session running on the server machine.
To give you control over exactly when data is transferred between client and server sessions, and when other requests from client to server occur.

The Progress Dynamics framework handles this data transfer and most other interactions between client and server in a standard way. The framework optimizes the interaction so that you do not need to modify it in most cases.

Another reason for using the AppServer is that it makes the application environment more flexible. In particular, using the Progress WebClient product, the client application can run without any database connection. Progress Dynamics supports the use of the AppServer to enable you to deploy your application, in this configuration or in new ones yet to be developed, without having to change your fundamental business logic.

However, building an application that uses the AppServer involves a very different mind-set from developing applications that run host-based or client/server. In fact, some useful features of the Progress language and how it interacts with the database are not appropriate in a distributed application. This can be a painful realization. You must think about it when designing or converting applications for this new environment.

Some of these differences center around record access and transaction scoping. Others arise because database data is not directly available on the client. Still others arise because an application that uses the AppServer involves two or more completely independent Progress sessions running on different machines. These are all things that you have to consider in your development. Progress Dynamics is designed to handle as many of these kinds of issues as possible for standard situations. But, there are always cases where you have to design and program with the characteristics of a distributed application in mind. The following sections discuss a few of these issues.